This invention relates generally to Java class files, and more particularly to the combination of such files into a run-time image.
Java is a relatively new object-oriented programming language that has become the subject of interest of many programmers. Ideally, Java is an architecture neutral and portable language, in that the same version of the program purportedly should run on any platform without modificationxe2x80x94i.e., a computer running a version of the Microsoft Windows operating system, a computer running a version of the Apple MacOS operating system, a computer running a version of the UNIX operation system, etc., should all be able to run the same version of a Java program. That is, there are purportedly no xe2x80x9cimplementation-dependentxe2x80x9d aspects of the Java language specification.
However, in reality, programs written in Java may not be realistically run on any platform without modification to allow for differences among different platforms, because of the inherent limitations and particularities of any given platform. For example, Microsoft Windows CE is a compact, efficient and scalable operating system that may be used in a wide variety of embedded products, from handheld PCs to specialized industrial controllers and consumer electronic devices. Many devices that utilize Microsoft Windows CE are intended to have a relatively low amount of random-access memory (RAM), such as one megabyte, to ensure that the devices remain low in cost, compact in size, and efficient in the usage of power. Further, devices designed to utilize Microsoft Windows CE typically have less powerful processors than what is typically found on computers designed to run more powerful operating systems like Microsoft Windows NT.
The nature of Java, however, is not necessarily consistent with the running of Java-written programs in such environments as Microsoft Windows CE. Java is both a compiled and an interpreted language. Java source code is turned into simple binary instructionsxe2x80x94called Java byte codes or J-codexe2x80x94much like ordinary microprocessor machine code. However, whereas C or C++ source code is refined to native instructions for a particular processor, Java source code is compiled into a universal format, instructions for what is known as a Java virtual machine.
The Java virtual machine thus is a native program running within an operating system to interpret and execute Java byte code. The fundamental unit of Java code is the class. As in other object-oriented languages, classes are application components that hold executable code and data. Compiled Java classes are distributed in a universal binary format that contains Java byte code and other class information. Classes may be maintained discretely and stored in files or archives on a local system or on a network server. Typically, classes are loaded and parsed dynamically at run-time, if they are needed by an application.
In other words, Java has been designed so that software implementations of the run-time system are able to optimize their performance by compiling byte-code to native machine code on the fly. A class file is loaded and parsed, such that it is compiled on a xe2x80x9cjust in timexe2x80x9d basis at run-time. Thus, when a Java program is run by a Java virtual machine, there are ultimately two versions of necessary class files: the byte-code versions that initially existed prior to the running of the program, and the loaded and parsed versions when the program is first run on the Java virtual machine.
There are several disadvantages to this design of the Java programming language in the context of platforms like the Microsoft Windows CE platform that are designed for efficiency and cost, and thus may not have as much memory as and have slower processors than, for example, desk-top computers running Microsoft Windows NT. First, the typical Java program uses many class files, such that loading and parsing these class files at run-time takes a long time on a less powerful processor. For example, it has been found that running a simple xe2x80x9cHello Worldxe2x80x9d programxe2x80x94e.g., a program that causes the words xe2x80x9cHello Worldxe2x80x9d to be displayed on the screenxe2x80x94may take more than nine minutes to execute on a handheld device having a processor running at about forty megahertz, because of the initial loading and parsing of class files at run-time.
One aspect of this initial loading and parsing is frequently the translation of the byte codes of the Java class files from big endian format to little endian format. That is, byte codes in Java class files are in big endian format such that the bytes are ordered from least significant to most significant (e.g., 0, 1, 2, 3), whereas on many platforms, little endian format is used, where bytes are to be ordered from most significant to least significant (e.g., 3, 2, 1, 0). Another aspect of this initial loading and parsing is that the Java class file format does not specify the location of a native member function, such that the virtual machine must search trough all the loaded files in a process to find the desired method.
A second distinct disadvantage ties into the fact that each Java class file contains a copy of all the data required to run that classxe2x80x94e.g., such as information regarding the superclasses to which the class is related. This data is often duplicated in other class files as well, wasting space unnecessarily. This is especially problematic in devices having limited amounts of RAM. For example, it has been found that in Java 1.1 (more specifically, Java Development Kit 1.1, or JDK 1.1), a simple xe2x80x9cHello Worldxe2x80x9d program has a run-time memory footprint of over 700 kilobytes in a given handheld device, or nearly seventy percent of an available one megabyte of RAM. Such a handheld device may also require about 300 kilobytes of RAM to maintain the screen, meaning that programs greater in complexity than a simple xe2x80x9cHello Worldxe2x80x9d program are not likely to run at all on the device.
Third, a related problem is that in a typical Java run-time system the Java class files are filed in storage. This may be RAM or read-only memory (ROM). When the Java virtual machine requires these files for execution, they are loaded into RAM and parsed, such that the resulting data are stored in RAM during execution. This means that during the running of a Java program, there are actually two versions of the needed class files stored on the machinexe2x80x94the unloaded and unparsed Java class files in storage (either RAM or ROM), and the loaded and parsed Java class files in RAM. For memory-constrained devices, this is burdensome.
There is a need, therefore, for a solution that overcomes these disadvantages and shortcomings of the loading and parsing of Java class files at run-time by a Java virtual machine, so that Java programs may realistically be more able to run on memory-constrained and slower platforms such as handheld devices running Microsoft Windows CE.
The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification. The invention describes combining multiple Java class files into a run-time image. The run-time image of the Java class files is such that class files are in a preloaded and pre-parsed state for a Java virtual machine. Desirably, the run-time image is a DLL file stored in read-only memory (ROM), and comprises non-redundant data.
The run-time image is desirably created by a separate utility that preloads and preparses a given collection of Java class files, such that the Java virtual machine does not have to load and parse the files at run time, but instead can rely on the run-time image itself. Desirably, this includes translating the byte codes of the Java class files from big endian format to little endian format, and also creating import records such that native member function data structures point thereto, permitting faster native member function resolution.
The invention therefore provides for advantages not found in the prior art. First, because the Java class files are preloaded and pre-parsed in the run-time image, the fact that the Java virtual machine does not have to load and parse them at run-time means that execution of Java programs is performed much more quickly. For example, it has been found that running a simple xe2x80x9cHello Worldxe2x80x9d program takes less than a second to execute on a handheld device having a processor running at about forty megahertz, as compared to more than nine minutes on the same device where the virtual machine must first load and parse the necessary class files.
Second, because desirably redundant data is eliminated when combining the loaded and parsed class files into a single DLL file, scarce space in memory is conserved. For example, it has been found that in Java 1.1.3 (more specifically, Java Development Kit 1.1.3, or JDK 1.1.3), a thirty-percent reduction in size of the run-time image file as compared to the prior art loading and parsing of class files at run time may be achieved in some instances.
Third, the run-time image is the only version of the Java class files that is needed within a given device. Furthermore, this only version is desirably stored in ROM, and not random-access memory (RAM). Thus, where in the prior art two versions of the class files exist, the first in an unloaded and unparsed state, and the second in a loaded and parsed state at run-time, and where often these two versions of the class files both exist in RAM by comparison, under the invention, there is only one version of the class files (just the loaded and parsed version), which desirably exists in ROM. This saves scarce RAM.
The present invention describes devices, computers, computer-readable media, and systems of varying scope. In addition to the aspects and advantages of the present invention described here, further aspects and advantages of the invention will become apparent by reference to the drawings and by reading the detailed description that follows.